# This setup is a bit out of the ordinary for a staging system. As the openqa
# scheduler needs up-to-date information from the wiki and koji, it doesn't
# work well as a proper staging host.
#
# We decided to keep it a pseudo-staging host that will get new versions of
# openqa first and will be a staging host for most intensive purposes but from
# a firewall rule POV, it will be a staging-friendly production host
#
# it should still be using the stg proxies and the external hostname will still
# be stg.fedoraproject.org

# this is to enable nested virt, which we need for disk image creation
virt_install_command: "{{ virt_install_command_one_nic }} --cpu=host-passthrough,+vmx"

deployment_type: stg
external_hostname: openqa.stg.fedoraproject.org
# makes sure it sends stg not prod fedmsgs
fedmsg_env: stg
freezes: false

openqa_assetsize_ppc: 300
openqa_assetsize_updates_ppc: 100
openqa_compose_arches: x86_64,aarch64,ppc64le
openqa_dbname: openqa-stg
openqa_dbpassword: "{{ stg_openqa_dbpassword }}"
openqa_dbuser: openqastg
openqa_env: staging
openqa_env_prefix: stg-
# this is because openqa staging isn't really a staging host
# we don't want to set env_suffix to stg on it because that may
# break some other plays, but we do need the env suffix for the
# fedora-messaging bits, so let's make our own
openqa_env_suffix: .stg
openqa_key: "{{ stg_openqa_apikey }}"
# all our workers need NFS access
openqa_nfs_workers: "{{ groups['openqa_lab_workers'] }}"
# install openQA from updates-testing - this is staging, we live
# ON THE EDGE (radical guitar riff)
openqa_repo: updates-testing
openqa_resultsdb_url: https://resultsdb.stg.fedoraproject.org/api/v2.0/
openqa_resultsdb_user: "{{ stg_resultsdb_httpd_user }}"
openqa_resultsdb_password: "{{ stg_resultsdb_httpd_password }}"
openqa_secret: "{{ stg_openqa_apisecret }}"
openqa_update_arches: ['x86_64', 'ppc64le']
openqa_webapi_plugins: FedoraMessaging
openqa_wikitcms_hostname: stg.fedoraproject.org
wikitcms_token: "{{ private }}/files/openidc/staging/wikitcms.json"
